Subject: Response to Frank B.: New Multicast Proposal (fwd)

From: Frank Bordonaro <[email-masked]>
Date: Sat, 13 Jul 1996 13:48:43 -0400 (EDT)

Dave,

I agree with you except that I am convinced UDP unicast of any packet 
can dramatically help scalability. Contradiction may have been too
strong of a word. Inconsistency in objective is really the problem.
Allowing for flexibility is a good thing in this case, in my opinion,
as long as we clearly define the flexibility. Having several sentences
that allow something and others that disallow it is inconsistent and
will make for a large headache if we attempt to interoperate.
I agree that we should get the RIGs to agree upon a direction with
respect to this matter.

I am prepared to outline the ways that UDP unicast of any packet
helps scalability. In general terms, I have covered this in my 
unicast post. Aside from the unicast issue, I think the multicast 
proposal is great. If we decide that sending any packet UDP unicast
is something we want, I'll be more than happy to help with the editing
burden.

Regards,
Frank

Forwarded message:
> From [email-masked] Fri Jul 12 17:34:19 1996
> Message-Id: <[email-masked]>
> To: aiw-dlsw-scalability <[email-masked]>
> Cc: Frank Bordonaro <[email-masked]>
> From: David Bryant/HQ/3Com
>   <[email-masked]>
> Date: 12 Jul 96 14:36:31 EDT
> Subject: Response to Frank B.: New Multicast Proposal
> Mime-Version: 1.0
> Content-Type: Text/Plain
> 
> Frank - 
> 
> Can't say I agree with your statements about contradictions.   Ambiguities 
> perhaps, but I don't believe the document contradicts itself.  If there are 
> contradictions, I'd  rather deal with them on a case by case basis.  That is, 
> if there are specific sentences that are in strict contradiction, let's 
> identify them, make a choice, and correct them.
> 
> I added the "Unicast and UDP datagrams in Lieu of IP Multicast" because  it 
> seemed to me to be much easier than to try and reconcile the text from your 
> proposal with the document.  
> 
> All that aside, I think, however, that we're having problems with mixed 
> objectives.  Over time, we have begun to shift all about on what we're trying 
> to accomplish.  The original proposal was to the DLSw Scalability SIG as a 
> general solution to some of the scalability problems.  The goal was to increase 
> DLSw scalability.  For this reason, implementation of single TCP connection was 
> required. But over time, other things are creeping in like UDP unicast for any 
> packet.  At the same time, there's something called "DLSw version 2" which is 
> supposed to be a follow-on to RFC 1795.   The content of DLSw Ver 2 has not yet 
> been defined.   I would hope that it contains the scalability enhancements 
> defined by the scalability sig.  But I'm not convinced that UDP of any packet 
> type is directly related to scalability in any way.  
> 
> In the meantime, I find myself thrashing a bit at the whims of scalability 
> sig.  At first, everyone wanted all kinds of detail on exactly how to use 
> multicast groups and addresses and peers.  Later, I was asked to remove it from 
> the document.  Then people wanted detail on how to use UDP unicast, when 
> unicast vs. mcast, etc.  Now I'm hearing arguments in favor of fewer rules, 
> greater flexibility, and every implementer to himself. 
> 
> Before investing effort in any direction, I'd like to get some input for the 
> others in the SIG regarding the UDP unicast issue, specification vs. ambiguity, 
> goals and content of this effort, and any other issues with the document.
> 
> Regards, Dave
> 
>  ----- Previous Message ---------------------------------------------------- 
> 
> 
> 
> To: aiw-siglets-dlsw-redist  @ 3mail.3com.com @ UGATE
> cc:  
> From: fbordona @ cisco.com (Frank Bordonaro) @ UGATE    
> Date: Friday  July 12, 1996 03:22 PM
> Subject: Re: New Multicast Proposal
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Dave,
> 
> I have a strong concern regarding the references to using unicast in 
> place of a multicast mechanism in the current proposal. In my opinion,
> there are too many contractdictions in the current proposal regarding
> when it is acceptable/recomended to send via UDP unicast.
> 
> The current multicast proposal contains a section entitle
> "Unicast and UDP Datagrams in Lieu of IP Multicast". This section states
> that "it is possible for implementations to simply make use of the UDP
> transport mechanism described in this paper without making direct use of
> the IP multicast function".
> 
> This is exactly the type of flexibilty that is behind my push for the addition
> of unicast-only support, but this section is not enough. The current multicast 
> proposal contains "shoulds" and "musts" throughout that discourage/prohibit use
> of unicasting when multicast "should/must" be used. 
> 
> In my opinion, we need to be more flexible and allow implementations 
> to send any frame via UDP unicast.  There are too many ways an 
> implementation can optimze traffic flow if it had this flexibility. For
> example, there are cases when a CanUReach_Ex/NAME_QUERY_ex should only be 
> sent to a subset of DLSw peer nodes for optimal scalability. This behavior 
> should be allowed and encouraged. As it reads in the NetBIOS section of the
> proposal, the table and note 2 in particular states that NAME_QUERY_ex
> "should always be multicast on the WAN".
> 
> I am not sure how to interpret these contradictions. Are we trying to 
> encorporate the support for sending of any  frame via UDP unicast?
> 
> It seems to me we have 2 choices.
> 
> 1) Clean up contradictions in the current proposal to explicity allow
>    the sending of any packet UDP unicast. In this case, the unicast 
>    proposal can go away.
> 
> 2) Clean up contradictions in the current proposal to explicity disallow
>    the sending of certain packets UDP unicast. If this route is chosen, I 
>    would like to see the Unicast proposal I posted on April 11 be integrated
>    as a sub-chapter in the DLSw Version 2 Scalability Document.
> 
> Before reading the current proposal, I thought we were going with option 2,
> but since the current multicast proposal tosses around the use of unicast
> in lieu of multicast, it may be easier for us as a group to work on one
> proposal and make it satisfy all requirements.
> 
> Regards,
> Frank Bordonaro
> cisco Systems, Inc.
> 
> 
> 
>   
>